GROUP INFORMATION TECHNOLOGY DEPARTMENT
RELEASE MANAGEMENT POLICY & PROCEDURES
" Disclaimer: AlBabtain Group management considers the information contained in this document to be of confidential by nature and is a proprietary to AlBabtain Group. The distribution of this document should be controlled and be made available only to persons authorized by the CIO. No content of this document shall be copied, deconstructed or reproduced, except with a prior written approval from the Group IT management."
1. Policy Purpose and Scope
  1. To ensure that the integrity of the live environment is protected through efficient deployment of changes, by correctly planning, scheduling, designing, building and testing hardware and software components to release them in forms that are compatible, licensed and authorized.
  2. Release Management works within Change Management to protect the live/production environment, ensuring compatibility of all hardware and software where they are to be used together.
2. Policy Statement
  1. All hardware and software within the IT infrastructure including:
    • In-house developed applications
    • Externally developed software
    • Utility software
    • Systems software
    • Hardware and hardware specifications
    • Assembly instructions and documentation
    • User manuals
    • Network devices
  2. All authorized changes in the live environment
3. Procedures
  1. Release Coordinators Roles:
    1. Determine new changes to be added, new items such as (H/W, S/W, Patches, and Updates). New items are all hardware and software within the IT environment including:
      • In-house developed applications
      • Externally developed software
      • Utility software
      • Systems software
      • Hardware and hardware specifications
      • Assembly instructions and documentation
      • User manuals
      • Network devices
    2. Analyze impact on current infrastructure, affected systems, and develop the Business Impact Analysis.
    3. If the impact analysis is not approved, then update the implementation plan with the impact and update the release database. Otherwise, assign the release to the appropriate administrator.
    4. If the release is implemented successfully, then check the results and files the release documents such as (IP, Test Report) and any other documents exchanged during the Release Management Process and send copies of all documents to the IT head.
    5. Prepare RFC to update the CMDB and initiate the Change Management Process.
  2. Administrators Roles:
    1. Receive the items from the change initiator or vendor; test them for acceptance using an acceptance test form. Then the results may either be rejected or accepted on conditions previously agreed between the IT Department and the vendor.
    2. The objective is to ensure that the delivered items meet the business user requirements. The acceptance phase may also act as the final quality gateway, where any quality defects not previously detected may be uncovered.
    3. If any of the supplied items does not pass the acceptance test, the vendor is requested to resubmit items that are compliant with the acceptance standards.
    4. If the supplied items pass the acceptance test, then prepare rollout plan which is a plan that documents all actions to be taken to restore the service if the rollout of the release fails or partially fails. It may also be a plan for an alternate option to provide services at a defined level if a full restoration is physically impossible.
    5. Implement the change in the production environment according to the Implementation Plan, the timing of launching the release must be communicated with IT unit managers and heads who communicates the time with IT Department and other departments, interrupting other’s work can be avoided if the right timing is chosen for releasing the change.
    6. In case of release failure, execute the Back-out Plan, update the Release Database and initiate the Problem Management Process
    7. If the release is a success, document the release and update the CMDB by initiating the Configuration Management Process.
4. Relationships
  1. Configuration Management
    • The link with Configuration Management for input of relevant information for decision making and managing the changes, providing the information regarding what has changed, so that the CMDB can be properly updated.
  2. Problem Management
    • The Problem Management process is initiated whenever an implementation fails.
    • Problem Management uses the results of proper building and testing when a re-installation or a reversion to a previous good known state is required.
  3. Change Management
    • The Change Management Process is initiated, every time a Request for Change (RFC) is created. The Change Management is responsible for reflecting the changes done on the CI’s in the CMDB.
5. Authorization Matrix
5.1 RACI Legend
R The person(s) who is/are RESPONSIBLE for the process
A The person(s) who is/are ACCOUNTABLE about the process
C The person(s) who is/are CONSULTED in the process
I The person(s) who is/are INFORMED about the process
5.2 Roles Legend
Roles Job Title/ Role Name
Role “1” Release Coordinator
Role ”2” IT Administrator
5.3 RACI Chart
Procedure Role “1” Role “2”
Release Management
New hardware/ software to be released? I IC
Approve ordering new items from vendor I I
Receive the supplied items RA C
Check for acceptance RA C
Accepted? RA C
Assign an appropriate administrator RA I
Prepare back-out plan and update test report IC RA
Implement the change in the production environment according to the IP RC A
Implementation success? RIC A
Execute Back-out Plan RC A
Document the release and update CMDB IC RA
Check the results and file the release documents A CA
Send Release Documents to IT head RA -
P.S. The mentioned “RACI chart “procedures are built on standard practice and can be changed upon business and technology environment. And/or IT new frameworks, new roles & responsibilities across IT resources and business owners demand.

This document is intended for the internal use of AlBabtain Group and its subsidiaries only. Unauthorized usage or possession of this document in any form is strictly prohibited. The recipient should ensure that this document is not de-constructed, reproduced or circulated without prior approval from the document owner.